home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
NetNews Offline 2
/
NetNews Offline Volume 2.iso
/
news
/
comp
/
std
/
c
/
446
< prev
next >
Wrap
Internet Message Format
|
1996-08-06
|
3KB
Path: news.crd.ge.com!usenet
From: Christopher R Volpe <volpe@ash.crd.ge.com>
Newsgroups: comp.std.c
Subject: Re: sizeof(char) ~= sizeof(float)
Date: Mon, 26 Feb 1996 10:32:42 -0500
Organization: GE Corporate Research & Development, Schenectady, NY
Message-ID: <3131D29A.7475@ash.crd.ge.com>
References: <WALD.96Feb24131532@woodpecker.lcs.mit.edu>
NNTP-Posting-Host: bart.crd.ge.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.4 sun4m)
David Wald wrote:
>
[...]
> However, one quirk of this architecture was that not all
> interpretations of a memory word could see all bits. In particular,
> though integral types and floats each took one word, a float used 8
> more bits than the integral types. When a word was used in integral
> operations, the lower 8 bits were invisible and harmless. Thus you
> could have two sections of memory which could be distinguished when
> viewed through float*'s but not when viewed through char*'s.
>
> Can such an implementation be ANSI-conformant? The basic argument
> against, presented by Tanmoy Bhattacharya, is that memory compare, and
> possibly memory copy functions, can't be implemented in a portable
> fashion if two dissimilar regions of memory can't be distinguished by
> comparing them char-wise.
I don't think this is relevant. At issue here is the behavior of
strictly conforming code presented to the implementation, not the ease,
or even possibility, of implementing the standard library using the
language of the compiler.
The implementation is required to provide a memcmp function that works
as described. If that requires the implementation of memcmp to compare
floats instead of chars, or to use an assembler octet-compare
instruction, then so be it. And it's none of your business whether or
not it does that.
> (I'm unsure about the memory copy, since
> I've forgotten whether the implementation actually preserved the
> hidden 8 bits when you copied a char.) Does this violate a constraint
> of the standard?
"Constraints" are imposed upon user programs, not compiler
implementations. Though you probably meant "constraint" in the looser
sense, not in the specific ANSI sense. In that case, the one sure-fire
way to demonstrate non-conformance is to present a strictly conforming
program, whose behavior will be clearly discernable by reading the
Standard, that elicits improper output from the compiler in question.
So, can you produce such a program?
--
Chris Volpe Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D Fax: (518) 387-6560
PO Box 8, Schenectady, NY 12301 Email: volpecr@crd.ge.com